[Owncloud] Debug slow webinterface (OC 6.0.0a)

2014-01-15 Thread Tobias Brunner

Hi,

The webinterface on version 6.0.0a is loading very slow for me. From the 
login page until everything is loaded it takes over 25s. I have other 
webapplications running on the same server (f.e. roundcube) and they are 
very fast. The server is running Debian Wheezy, PHP is loaded as Apache 
module and PHP has the APC cache module enabled. There are only a few 
default modules activated in ownCloud.


How can I debug this performance issue to find out where the bottleneck 
is?


Thanks for any advice.

Cheers,
Tobias

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


[Owncloud] How much ownCloud db takes?

2014-01-15 Thread Vladimir Sapronov
I know it depends on files amount and usage but I want to know at least
some experiences.

I want to serve 2-3 users with ~100Gb (25000 files) each without changes
history. I have ~3 Gb of free space on the disk specifically for owncloud
mySQL db. I need to ballpark for how many files and for what period of time
my space will be enough.

Thanks,
Vladimir Sapronov
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] How much ownCloud db takes?

2014-01-15 Thread Michael
You should be fine. I have 10k files and around 30gb and only use 61MB.


On Wed, Jan 15, 2014 at 8:40 AM, Vladimir Sapronov <
vladimir.sapro...@gmail.com> wrote:

> I know it depends on files amount and usage but I want to know at least
> some experiences.
>
> I want to serve 2-3 users with ~100Gb (25000 files) each without changes
> history. I have ~3 Gb of free space on the disk specifically for owncloud
> mySQL db. I need to ballpark for how many files and for what period of time
> my space will be enough.
>
> Thanks,
> Vladimir Sapronov
>
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>
>
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] Debug slow webinterface (OC 6.0.0a)

2014-01-15 Thread Otto Kekäläinen
I've noticed the same slowness thing in the web UI at multiple
installations. Can you open the web console (e.g. F12 on Chromium or
F12 for Firebug in Firefox) and see what request exactly is slow?
list.php?

What database do you run, SQLite?

2014/1/15 Tobias Brunner :
> Hi,
>
> The webinterface on version 6.0.0a is loading very slow for me. From the
> login page until everything is loaded it takes over 25s. I have other
> webapplications running on the same server (f.e. roundcube) and they are
> very fast. The server is running Debian Wheezy, PHP is loaded as Apache
> module and PHP has the APC cache module enabled. There are only a few
> default modules activated in ownCloud.
>
> How can I debug this performance issue to find out where the bottleneck is?
>
> Thanks for any advice.
>
> Cheers,
> Tobias
>
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud



-- 
Otto Kekäläinen
+358 44 566 2204
http://seravo.fi/
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] How much ownCloud db takes?

2014-01-15 Thread Marcel Herrguth

Hello,

Am 15.01.2014 15:40, schrieb Vladimir Sapronov:

I want to serve 2-3 users with ~100Gb (25000 files) each without changes
history. I have ~3 Gb of free space on the disk specifically for
owncloud mySQL db. I need to ballpark for how many files and for what
period of time my space will be enough.


I don't have that much files, but am serving 5 Users, with overall 3,000 
files (at about 2 GB). We use owncloud mainly for contacts and calendar 
functions. Right now the database takes about 10 MB space.


Best regards
Marcel


--
www.mrgeneration.de - The home of Anime
Marcel Herrguth   Tel: 0176/65 92 44 85
Klüberstr. 25
12249 Berlin, Germany

The home of Anime @
Facebook:https://www.facebook.com/mrgeneration.de
Twitter: https://twitter.com/Mr_Generation

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] Debug slow webinterface (OC 6.0.0a)

2014-01-15 Thread Tobias Brunner

Hi,


I've noticed the same slowness thing in the web UI at multiple
installations. Can you open the web console (e.g. F12 on Chromium or
F12 for Firebug in Firefox) and see what request exactly is slow?
list.php?

What database do you run, SQLite?


Yes, I'm using SQLite, or better, I WAS using SQLite. I've just switched 
to MySQL and ownCloud is now MUCH faster!


Thanks for this hint...

Cheers,
Tobias

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


[Owncloud] switching from sqlite to mysql

2014-01-15 Thread Reinoud van Leeuwen
Hi, does an 'official' manual exist which describes how to switch from SQLite 
to MySQL? I did not find it under 
http://doc.owncloud.org/server/6.0/admin_manual/maintenance/migrating.html

I've found 
http://fabianpeter.de/cloud/owncloud-migrating-from-sqlite-to-mysql/, but that 
does not work for my 6.0 installation.

When I take the SQLite dump and remove the create table statements, and take a 
fresh MySQL dump from a just-installed 6.0 installation, I have another 
problem: it seems that in my SQLite installation a table oc_fscache is present, 
which is missing in the Mysql Dump...

So I would like a migration path which will not lead to surprises like this now 
or during the next upgrade...

And I think I am not the only one that will do this migration after some time 
using owncloud.

Thanks,
Reinoud
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] Owncloud on Fedora/RHEL 6

2014-01-15 Thread Matěj Cepl


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014-01-13, 21:25 GMT, you wrote:
> And here is the problem: Fedora 19 (!) seems to provide 
> ownCloud 4.5.13 which is about nine month old. That's not what 
> people want. They want ownCloud 6. And we seek a way to 
> provide them, even if they are on Fed19.

And if insted of pushing new version to your system (or OpenSUSE 
build) you would push it to the Koji, then you would have build 
for Rawhide and -testing distros in the same time. When I was 
working as part of the team dealing with Mozilla programs 
(Firefox and Thunderbird) we were proud to have 0day upgrades.  
I don’t see the reason why you couldn’t have the same in Fedora 
(note, Fedora is not RHEL so updates and rebases are mostly 
decision of the maintainers).

> Yes, I know, I worked long enough for another distro. But one 
> of the distro communities problems is that they don't really 
> face todays reality: As said above, people want to have 
> up-to-date apps. And if a new version (!) comes out, they 
> wanna use it and not hear "Well, you have a nine month old 
> version, and we will provide you with security fixes. Be 
> happy!"

I am not sure which distro you are talking about. If you think 
Debian/stable, then RHEL is not exactly like that. Of course, 
stability is very very important, but it is not exactly 
completely dead frozen stability as with the Debian/stable (and 
this is not meant to say anything against Debian maintainers ...  
when I see how incredible amount of work my colleagues have to 
spend on keeping RHEL together, I fully understand Debian with 
its limited resources is not capable of such feat). Notice that 
we have many server side (even PHP) programs in EPEL 
(https://fedoraproject.org/wiki/EPEL), and if you think that 
keeping up with WordPress 
(http://koji.fedoraproject.org/koji/packageinfo?packageID=4118) 
is so simple, then you are badly mistaken. For example, we had 
to create php53 for it (or because of Zarafa 
http://koji.fedoraproject.org/koji/packageinfo?packageID=9907, 
another not exactly simple package to maintain).

> They don't wanna have their operating system platform having 
> dictating the versions of the apps they're using.

??? Nobody dictates you anything, if you put you hand down to 
the shovel.

> You might want to check how that is on other, successful 
> platforms like android how it works there. Time has changed 
> a bit, and we as distro guys shouldn't close the eyes IMHO.

If you think that the mess of multiple copies of huge libraries 
bundled in individual packages half of them unmaintained (a mess 
from which Java folks are trying to get out ...  
http://openjdk.java.net/projects/jigsaw/ ... so far 
unsuccessfully) and thus half of them with unpatched security 
vulnerabilities makes me envious, then you are sorely mistaken.  
I don’t mind if people put such mess on their phones (their 
problem), but to have something like that on server doesn’t seem 
like a good idea. Yes, many people do it, but probably mostly 
because they have no other choice (especially in Java world 
which lacks appropriate technology), but a part of the Fedora’s 
mission is to provide excellent engineering. This doesn’t seem 
like a way there.

BTW, so far, RHEL customers seem to agree with this opinion.

> Of course not. This is speed: If ownCloud upstream releases 
> a new ownCloud version, the users can install it through their 
> distro package manager an hour later. 6.0.0a on Fedora 19.

As I said, as the old rabbi said ... it depends just on you.

> Whooohooo, now you're starting! Please calm down a bit, we're 
> not doing bad stuff intentional.

I didn’t say that. Just that because you are doing your separate 
community, you didn’t have time and resources to do it 
correctly. Completely without any sneering, how should I report 
bugs against your RHEL packaging? GitHub Issue tracker?

> a) RHEL 6 ships Qt 4.6 IIRC. That is so much outdated that we could not 
> backport the client without taking too much away. And RHEL not being 
> desktop system no 1 on the planet, we decided to ship an useful Qt 
> version in /opt/. I know, distro people hate that, but please consider 
> reality here as well. What do users want? A _working_ solution. And I 
> don't think that the Qt in /opt/.. steps in the way of anything else on 
> the system as we also provide wrapper scripts.

What do users want? Well, users of RHEL want also _maintained_ 
solution. Are you certain you will maintain Qt (it is a huge 
library) as well as Fedora maintainers? As I said we have php53 
package (for EPEL 5; don’t tell me how RHEL-6 is obsolete before 
supporting RHEL-5 ;)), or perhaps somebody can think about 
patching reasonable subset of owncloud-client to work with old 
Qt, or perhaps old owncloud-client can be patched to work with 
new server API. Something. Reasonable people are able to 
negotiate solutions for their problems.  

> b) issue tracker: https://github.com/owncloud/mir

Re: [Owncloud] switching from sqlite to mysql

2014-01-15 Thread Diederik de Haas
On Wednesday 15 January 2014 21:39:19 Reinoud van Leeuwen wrote:
> I have another problem: it seems that in my SQLite installation a table
> oc_fscache is present, which is missing in the Mysql Dump...

Just create that table, or leave it out all together. It is meant to cache 
things, so if it's not present, it will be created (and filled).
I've cleared that table many times during testing, so afaik it's safe to leave 
it out.

-- 
GPG: 0x138E41915C7EFED6

signature.asc
Description: This is a digitally signed message part.
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] switching from sqlite to mysql

2014-01-15 Thread Reinoud van Leeuwen

On 15 jan. 2014, at 21:56, Diederik de Haas  wrote:

> On Wednesday 15 January 2014 21:39:19 Reinoud van Leeuwen wrote:
>> I have another problem: it seems that in my SQLite installation a table
>> oc_fscache is present, which is missing in the Mysql Dump...
> 
> Just create that table, or leave it out all together. It is meant to cache 
> things, so if it's not present, it will be created (and filled).
> I've cleared that table many times during testing, so afaik it's safe to 
> leave 
> it out.

Next thing I stumble upon is:

ERROR 1062 (23000) at line 5269: Duplicate entry 
'calendar/appinfo/remote.php-core' for key 'PRIMARY'

Makes sense since the create table statement is 

CREATE TABLE `oc_appconfig` (
  `appid` varchar(32) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `configkey` varchar(64) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
  `configvalue` longtext COLLATE utf8_unicode_ci,
  PRIMARY KEY (`appid`,`configkey`),

and in the dump are lines:

INSERT INTO `oc_appconfig` 
VALUES('calendar/appinfo/remote.php','core','remote_calendar');
INSERT INTO `oc_appconfig` 
VALUES('calendar/appinfo/remote.php','core','remote_caldav');


So, someone might know how to fix this particular problem, but my point is that 
from a application maintainer perspective I do not feel really good having to 
hack like this in SQL dumps to get this working. And it sounds like the 
database is different on SQLite, otherwise this would not have been present in 
the database at all..
Or is this the result from buggy updates?

Reinoud
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] switching from sqlite to mysql

2014-01-15 Thread Otto Kekäläinen
I tried this migration a few days ago (look at the mailing list
history with author my name), and I after manually fixing many many
things I eventually gave up. At the moment there is no working
migration script.

Today I reinstalled one OwnCloud installation with MySQL and simply
re-created the users and moved the files. A bit of work, but at the
moment the best option. Hopefully an official migration script would
be made at some point. Even better if SQLite was not default, not even
for home users..

2014/1/15 Reinoud van Leeuwen :
>
> On 15 jan. 2014, at 21:56, Diederik de Haas  wrote:
>
>> On Wednesday 15 January 2014 21:39:19 Reinoud van Leeuwen wrote:
>>> I have another problem: it seems that in my SQLite installation a table
>>> oc_fscache is present, which is missing in the Mysql Dump...
>>
>> Just create that table, or leave it out all together. It is meant to cache
>> things, so if it's not present, it will be created (and filled).
>> I've cleared that table many times during testing, so afaik it's safe to 
>> leave
>> it out.
>
> Next thing I stumble upon is:
>
> ERROR 1062 (23000) at line 5269: Duplicate entry 
> 'calendar/appinfo/remote.php-core' for key 'PRIMARY'
>
> Makes sense since the create table statement is
>
> CREATE TABLE `oc_appconfig` (
>   `appid` varchar(32) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
>   `configkey` varchar(64) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
>   `configvalue` longtext COLLATE utf8_unicode_ci,
>   PRIMARY KEY (`appid`,`configkey`),
>
> and in the dump are lines:
>
> INSERT INTO `oc_appconfig` 
> VALUES('calendar/appinfo/remote.php','core','remote_calendar');
> INSERT INTO `oc_appconfig` 
> VALUES('calendar/appinfo/remote.php','core','remote_caldav');
>
>
> So, someone might know how to fix this particular problem, but my point is 
> that from a application maintainer perspective I do not feel really good 
> having to hack like this in SQL dumps to get this working. And it sounds like 
> the database is different on SQLite, otherwise this would not have been 
> present in the database at all..
> Or is this the result from buggy updates?
>
> Reinoud
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud



-- 
Otto Kekäläinen
+358 44 566 2204
http://seravo.fi/
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] switching from sqlite to mysql

2014-01-15 Thread Frank Karlitschek
We are working on providing a DB migration script. Here is a pull request that 
is still work in progress:
https://github.com/owncloud/core/pull/6457
Any help with coding and testing is highly appreciate.


Frank


On 15.01.2014, at 16:17, Otto Kekäläinen  wrote:

> I tried this migration a few days ago (look at the mailing list
> history with author my name), and I after manually fixing many many
> things I eventually gave up. At the moment there is no working
> migration script.
> 
> Today I reinstalled one OwnCloud installation with MySQL and simply
> re-created the users and moved the files. A bit of work, but at the
> moment the best option. Hopefully an official migration script would
> be made at some point. Even better if SQLite was not default, not even
> for home users..
> 
> 2014/1/15 Reinoud van Leeuwen :
>> 
>> On 15 jan. 2014, at 21:56, Diederik de Haas  wrote:
>> 
>>> On Wednesday 15 January 2014 21:39:19 Reinoud van Leeuwen wrote:
 I have another problem: it seems that in my SQLite installation a table
 oc_fscache is present, which is missing in the Mysql Dump...
>>> 
>>> Just create that table, or leave it out all together. It is meant to cache
>>> things, so if it's not present, it will be created (and filled).
>>> I've cleared that table many times during testing, so afaik it's safe to 
>>> leave
>>> it out.
>> 
>> Next thing I stumble upon is:
>> 
>> ERROR 1062 (23000) at line 5269: Duplicate entry 
>> 'calendar/appinfo/remote.php-core' for key 'PRIMARY'
>> 
>> Makes sense since the create table statement is
>> 
>> CREATE TABLE `oc_appconfig` (
>>  `appid` varchar(32) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
>>  `configkey` varchar(64) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
>>  `configvalue` longtext COLLATE utf8_unicode_ci,
>>  PRIMARY KEY (`appid`,`configkey`),
>> 
>> and in the dump are lines:
>> 
>> INSERT INTO `oc_appconfig` 
>> VALUES('calendar/appinfo/remote.php','core','remote_calendar');
>> INSERT INTO `oc_appconfig` 
>> VALUES('calendar/appinfo/remote.php','core','remote_caldav');
>> 
>> 
>> So, someone might know how to fix this particular problem, but my point is 
>> that from a application maintainer perspective I do not feel really good 
>> having to hack like this in SQL dumps to get this working. And it sounds 
>> like the database is different on SQLite, otherwise this would not have been 
>> present in the database at all..
>> Or is this the result from buggy updates?
>> 
>> Reinoud
>> ___
>> Owncloud mailing list
>> Owncloud@kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
> 
> 
> 
> -- 
> Otto Kekäläinen
> +358 44 566 2204
> http://seravo.fi/
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


Re: [Owncloud] switching from sqlite to mysql

2014-01-15 Thread Reinoud van Leeuwen
Thanks! I'll take a look at it.

Reinoud

On 15 jan. 2014, at 22:41, Frank Karlitschek  wrote:

> We are working on providing a DB migration script. Here is a pull request 
> that is still work in progress:
> https://github.com/owncloud/core/pull/6457
> Any help with coding and testing is highly appreciate.
> 
> 
> Frank
> 
> 
> On 15.01.2014, at 16:17, Otto Kekäläinen  wrote:
> 
>> I tried this migration a few days ago (look at the mailing list
>> history with author my name), and I after manually fixing many many
>> things I eventually gave up. At the moment there is no working
>> migration script.
>> 
>> Today I reinstalled one OwnCloud installation with MySQL and simply
>> re-created the users and moved the files. A bit of work, but at the
>> moment the best option. Hopefully an official migration script would
>> be made at some point. Even better if SQLite was not default, not even
>> for home users..
>> 
>> 2014/1/15 Reinoud van Leeuwen :
>>> 
>>> On 15 jan. 2014, at 21:56, Diederik de Haas  wrote:
>>> 
 On Wednesday 15 January 2014 21:39:19 Reinoud van Leeuwen wrote:
> I have another problem: it seems that in my SQLite installation a table
> oc_fscache is present, which is missing in the Mysql Dump...
 
 Just create that table, or leave it out all together. It is meant to cache
 things, so if it's not present, it will be created (and filled).
 I've cleared that table many times during testing, so afaik it's safe to 
 leave
 it out.
>>> 
>>> Next thing I stumble upon is:
>>> 
>>> ERROR 1062 (23000) at line 5269: Duplicate entry 
>>> 'calendar/appinfo/remote.php-core' for key 'PRIMARY'
>>> 
>>> Makes sense since the create table statement is
>>> 
>>> CREATE TABLE `oc_appconfig` (
>>> `appid` varchar(32) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
>>> `configkey` varchar(64) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
>>> `configvalue` longtext COLLATE utf8_unicode_ci,
>>> PRIMARY KEY (`appid`,`configkey`),
>>> 
>>> and in the dump are lines:
>>> 
>>> INSERT INTO `oc_appconfig` 
>>> VALUES('calendar/appinfo/remote.php','core','remote_calendar');
>>> INSERT INTO `oc_appconfig` 
>>> VALUES('calendar/appinfo/remote.php','core','remote_caldav');
>>> 
>>> 
>>> So, someone might know how to fix this particular problem, but my point is 
>>> that from a application maintainer perspective I do not feel really good 
>>> having to hack like this in SQL dumps to get this working. And it sounds 
>>> like the database is different on SQLite, otherwise this would not have 
>>> been present in the database at all..
>>> Or is this the result from buggy updates?
>>> 
>>> Reinoud
>>> ___
>>> Owncloud mailing list
>>> Owncloud@kde.org
>>> https://mail.kde.org/mailman/listinfo/owncloud
>> 
>> 
>> 
>> -- 
>> Otto Kekäläinen
>> +358 44 566 2204
>> http://seravo.fi/
>> ___
>> Owncloud mailing list
>> Owncloud@kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
> 
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
> 

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


[Owncloud] doctrine result caching in OC6?

2014-01-15 Thread Jakub Moscicki
Hello,

Anyone knows if Doctrine result cache may be safely enabled in owncloud 6? That 
would limit the number of excessive queries to the DB by a lot… 

kuba

--
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


[Owncloud] Solaris ZFS + ownCloud.

2014-01-15 Thread 瀧 康史
Hello.


We are making our service based on ownCloud6.0a for our customers.
This service is hosted on Solaris11 with zfs.

We already wrote some patches for porting solaris 11 and made solaris11 
packages( for IPS system).
And, we intend to improve owncloud for zfs.


Sure, I know this source code and patches under AGPL *or* your license.


We have some questions.

Which better for you ?

A. We(I and my coworkers) should sign your contribution agreement before we 
send some patches to you. 
  Sure, this patches and improvement sources are managed on your license.
B. We open some patches somewhere.(ex. github..) under AGPL.
C. We send some patches here under AGPL.

Our purpose is only making good service for our customer, 
we do *not* intend to insist the attribution of our contribution source code.


Regards,
TAKI.

---
JUSTPLAYER Co.,Ltd.
-When you want is when you play-

CEO/CTO, Board Director, Founder
TAKI, Yasushi

ZIP 420-0039
KawamuraKamigokucho Bldg 1F
2-4,Kamigokucho, Aoi-ku
Shizuoka City, Shizuoka.
mailto:t...@justplayer.com http://www.justplayer.co.jp/
Blog: http://kohju.justplayer.com/
Twitter: http://twitter.com/kohju
Facebook
http://www.facebook.com/taki.yasushi

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud