[Vtigercrm-developers] Input on optizing VT performance?
Stefan Warnat
ich at stefanwarnat.de
Wed Aug 3 08:54:43 GMT 2016
Hy,
To HHVM:
*The most important one at first*: Every feature of
Vtiger/PDFMaker/EmailMaker works! I never found one function I cannot use.
And I/we use it in production for a huge client, which would directly
complain about a problem.
Facebook take a look to be more compatibly a little bit. (Not generally all
PHP is compatible, but nothing within vtiger)
Maybe you don't trust my benchmark and I couldn't believe it myself. Maybe
in production environment I had some special MySQL Improvements.
But in production I use mysql replication, which gave a very little
decreased performance.
I have two similar systems with ~200 000 Records in crmentity. (I must say
VtigerCRM 6.2)
1 Testing system - On PHP 5.6:
1 Open the Invoice overview with 30 records and the loading time is ~1.5
sec.
1 Production - On HHVM:
I open the Overview of Invoices with 50 Records and the loading time is
475ms.
An explanation could be, like Alan means, Vtiger heavily works inside
to_html function. HHVM extremely optimize often used functions.
But I never try to figure out, why it is so fast.
Stefan
----
*Freelancer at Webdevelopment*
Web: http://www.stefanwarnat.de
Xing: https://www.xing.com/profile/Stefan_Warnat2
LinkedIn: http://www.linkedin.com/pub/stefan-warnat/6/827/820
eMail: kontakt at stefanwarnat.de
On Wed, Aug 3, 2016 at 10:37 AM, IT-Solutions4You <info at its4you.sk> wrote:
> I mean not wrong indexes but missing indexes in vtiger, like at all cf
> tables no index at id field and from this reason each JOIN acount.id =
> vtiger_accountscf.accountid take more time. Second bigg point si that NO
> fields like invoice_no is not indexed and I suppose you search for invoice
> no very often.
>
> This old forge project can be start point
> http://forge.vtiger.com/projects/vtsql-opt/. It's for 5.4 version I don't
> know if there is any implementation in vtiger 6.x
>
> Matus
>
> Dňa 3. 8. 2016 o 9:57 socialboostdk napísal(a):
>
>> I fully agree that wrong index will cause big loss of speed.
>>
>> Where do you see indexing problems in vt db?
>>
>> Thanks!
>> Chris
>>
>> On 3 August 2016 at 09:33, IT-Solutions4You
>> <info at its4you.sk
>> <mailto:info at its4you.sk>> wrote:
>>
>> > If you really looking into performance, hardware is the
>> > final benchmark.
>>
>> I'm sorry but I disagree with this opinion. Right index DB setting
>> increase the speed of the system without hardware changes. And
>> vtiger need better indexes at all
>>
>> Matus.
>>
>>
>> Dňa 2. 8. 2016 o 19:02 Sutharsan Jeganathan napísal(a):
>>
>> Hi Chris
>>
>> I would like to know whether HHVM is running at production
>> environment
>> with vtiger 6.4 and almost all features are used? how much % of
>> performance it gives? If there is a significant improvement can
>> be
>> achieved I would like to try it.
>>
>> In my experience, nginx gives little bit more than apache, but
>> again
>> setup effort is needed.
>>
>> @socialboostdk : If you really looking into performance,
>> hardware is the
>> final benchmark. From my experience, still vtiger struggles when
>> database size increases simaltaniously. Which could not be
>> resolved
>> through front end optimization or backend optimization, but the
>> hardware. Even if the database size is static, performance could
>> be
>> highly guaranteed by hardware only.
>>
>> Other question is, whether you need an overall performance, or
>> to a
>> specific section, such as summary view? We did some solutions by
>> replacing summary view with single page concept with lazy
>> loading which
>> provides a horizontal increase of page access time
>>
>>
>> Thanks
>> Sutharsan Jeganthan
>>
>> On Tue, Aug 2, 2016 at 6:27 PM, socialboostdk
>> <socialboostdk at gmail.com
>> <mailto:socialboostdk at gmail.com>
>> <mailto:socialboostdk at gmail.com
>> <mailto:socialboostdk at gmail.com>>>
>> wrote:
>>
>> Hi Alan and Stefan,
>>
>> Thank you for very good input!
>>
>> My takeaway is then that I will look at updating libs +
>> implementing
>> HHVM.
>>
>> Alan, for the js libs - is this integrated in v6.5? And/or
>> can i
>> support your work here in a way where we can get it in future
>> versions so we dont have to do redundant work?
>>
>> Stefan - thank you very much, this sounds very interesting.
>> I have a
>> good sysadmin, so i will ask him to look at it. Do you have
>> experience w. running VT on HHVM?
>>
>> Thanks for great input!
>>
>> Cheers,
>> Chris
>>
>> On 2 August 2016 at 14:22, Stefan Warnat
>> <ich at stefanwarnat.de
>> <mailto:ich at stefanwarnat.de>
>> <mailto:ich at stefanwarnat.de
>>
>> <mailto:ich at stefanwarnat.de>>> wrote:
>>
>> Hy Chris,
>>
>> This is not worth the time. (Sorry) ;) Because you will
>> spend
>> too much time during analyse of code, which you could
>> invest
>> better, because there already is a stable solution
>> available.
>> Ask your Sysadmin to install HHVM from Facebook. This is
>> much
>> fast then you reach with micro optimization.
>>
>> *AND*: This have a much better compatibility then PHP7
>> and also
>> runs with Vtiger < 6.5 with all modules. Only the setup
>> is a
>> little bit tricky. But you get a 100% faster result
>> within 2-3
>> hours.
>>
>> And I would use 6.5, because like Alan means, it is
>> faster, too
>> and also runs with HHVM. I would not use PHP7 with
>> Vtiger, now,
>> because you will get too much headaches.
>>
>> Stefan
>>
>>
>> ----
>> *Freelancer at Webdevelopment*
>>
>> Web: http://www.stefanwarnat.de
>> Xing: https://www.xing.com/profile/Stefan_Warnat2
>> LinkedIn:
>> http://www.linkedin.com/pub/stefan-warnat/6/827/820
>> eMail: kontakt at stefanwarnat.de
>> <mailto:kontakt at stefanwarnat.de>
>> <mailto:kontakt at stefanwarnat.de
>> <mailto:kontakt at stefanwarnat.de>>
>>
>>
>> On Tue, Aug 2, 2016 at 1:45 PM, Alan Bell
>> <alan.bell at libertus.co.uk
>> <mailto:alan.bell at libertus.co.uk>
>>
>> <mailto:alan.bell at libertus.co.uk
>>
>> <mailto:alan.bell at libertus.co.uk>>> wrote:
>>
>>
>> On 02/08/16 12:34, socialboostdk wrote:
>>
>> Hi there,
>>
>> I'm looking at optimizing the performance of VT,
>> ie.
>> compressing CSS, JS, etc. It also seems that
>> there are
>> many "overwrites" in the CSS where the same class
>> is
>> styled many times, etc.
>>
>> JS/CSS optimising is mostly client side performance,
>> which
>> frankly on modern PCs (or even phones/tables) isn't
>> much of
>> an issue. I think the main thing to do with that is
>> to get
>> all the javascript libraries updated from their
>> sources and
>> organised in a way that means they can be easily
>> updated in
>> future. This is something I started in this branch
>>
>>
>> http://code.vtiger.com/alanbell/vtigercrm/tree/javascript_library_updates
>>
>>
>> Does anyone have any experience in doing this
>> and/or
>> pointers on where to begin to get "maximum
>> efficiency" for
>> optimal effort?
>>
>> yes, use xdebug to profile what it does in PHP, where
>> it
>> spends it's time rendering a page (prior to 6.5 it was
>> pretty much all in the to_html function, 6.5 is a
>> lot faster)
>> You can make sure apache caches things correctly,
>> and use an
>> opcode cache for a general php performance boost.
>> If you spot any improvements please contribute them to
>> code.vtiger.com <http://code.vtiger.com>
>> <http://code.vtiger.com>
>>
>>
>> Ie. perhaps some obvious optimisations, etc.
>>
>> Thanks :)
>>
>> Best,
>> Chris
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>>
>
> _______________________________________________
> http://www.vtiger.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20160803/ba7a41a8/attachment-0001.html>
More information about the vtigercrm-developers
mailing list